1. Field of the Invention
The present invention relates to selection of an Internet Protocol (IP) source address for a host device to access a destination via a multi-homed site having multiple paths to the destination. In particular, the present invention relates to communicating, to a host device in the multi-homed site, default router preferences from a default gateway router configured for providing to the host device an access connection to the multi-homed site.
2. Description of the Related Art
A multi-homed site is a site (e.g., a private local area network or wide area network) which has more than one connection to a public wide area network, such as the Internet. The multiple connections by the site may be provided by a single Internet Service Provider (ISP) providing multiple links to the public wide area network, or by different ISPs providing respective links to the public wide area network. In addition, the multiple links may be located at separate geographic locations. Advantages to a multi-homed site include improved fault tolerance, load-balancing, etc.
Multi-homing solutions today apply to both IPv4 and IPv6 networks: a site obtains a dedicated block of address space (i.e., a prescribed address prefix) from each ISP, and assuming multiple ISPs are employed, the site advertises the routes for the respective address prefixes via the respective ISP connections. A disadvantage of advertising multiple prefixes, however, is that it multiplies the number of routes that need to be distributed throughout the “Default Free Zone” (DFZ) between the site and the public wide area network.
The Internet Engineering Task Force (ETF) has established a Working Group, entitled the “Site Multihoming in IPv6 (multi6)” Working Group, that addresses technical issues associated with implementing a multi-homed site. As described on the “Multi6” working group web site, publicly available at the web site address “ietf.org/html.charters/multi6-charter.html”, multihoming today is done largely by having a site obtain a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time.
The Multi6 Working Group has stated on its web page that it will seek alternative approaches with better scaling properties. Additional details regarding the goals for IPv6 site multihoming architectures is described in its Request for Comments (RFC) 3582.
One of the fundamental problems that need to be addressed in the context of multi-homed sites-involves the interaction between legacy host devices and ingress filtering by access routers providing a connection between the site and the public wide area network. In particular, a site having two access routers from respective ISPs and that follow source address ingress filtering rules may encounter packets being dropped if the packets do not comply with the source address ingress filtering rules. For example, the Internet Draft by Huitema et al., “Ingress filtering compatibility for IPv6 multihomed sites” (draft-huitema-multi6-ingress-filtering-00) describes that ingress filtering, normally used to verify the source address of the IP packets in order to prevent denial of service attacks based on using “spoofed” source addresses, actually may cause an access router to drop legitimate packets due to a host device utilizing an IP source address that is within an assigned address prefix of another access router and that is outside the address prefix range of the access router receiving the IP packet. Huitema et al. proposes minimizing ingress filtering conflicts by creating source address dependent (SAD) routing, where routers in the source based routing domain maintained as many parallel routing tables as there are valid source prefixes, causing the packets to exit the site to the appropriate router. Huitema et al. also proposes adding and exit router discovery mechanism within host devices to enable the host device to discover the preferred exit router for a given source address; hence, the host device can tunnel the packet directly to the adequate exit router.
Unfortunately, the source address selection in Huitema et al. is still performed randomly by the host device, and does not address that a given source address may be preferred in certain instances. Moreover, the above-identified Internet Draft by Huitema et al. does not address exploiting the advantage of redundancy in a multi-homing site. Further, the SAD routing proposed by Huitema et al. requires multiple instances of the routing protocol to be executed for respective prefixes; hence, each instance of the routing protocol only will possess knowledge learned through the corresponding ISP associated with the address prefix: if one of the ISPs encounters a failure, the default route will not be advertised by the corresponding exit router, causing routers within the site to remove the default route entry from their default routing tables; however, the multi-homed host device will be unaware of the unavailability of the failed ISP. Hence, a problem arises that a multi-homed host device may continue to send packets using a source address derived from an address prefix that has been assigned by the failed ISP.
One proposal for multi-homed host devices is described in an Internet Draft by Draves et al., entitled “Default Router Preferences and More-Specific Routes” (draft-ietf-ipv6-router-selection-07.txt), that extends Neighbor Discovery as described in RFC 2461 by modifying “router advertisement messages” (i.e., layer 2 neighbor discovery messages sent to connected on-link hosts) to include preference information. In particular, Draves et al. and RFC 2461 describe sending neighbor discovery messages to hosts that are connected on the same link: Section 2 of RFC 2461 defines “neighbors” as “nodes attached to the same link”, where a “link” is defined as “a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP”; hence, the neighbor discovery messages are described herein as “layer2 neighbor discovery messages” because they require that a host be connected to the router via a single connecting link.
Draves et al. describes that a router outputs a layer 2 neighbor discovery message that specifies a “preference value” indicating whether the router should be preferred as a default router over other routers; the layer 2 neighbor discovery message also can specify a Route Information Option field indicating whether the router should be preferred over other routers in reaching a corresponding specified address prefix. Hence, the host device receiving the layer 2 neighbor discovery message according to Draves et al. can build its own routing table, where each routing table entry specifies a prefix, prefix length, preference value, lifetime, and next-hop router. The host device can then search its routing table for the most preferred next-hop router for reaching an “off-link” destination address prefix (i.e. an address prefix that is not assigned to any interface on a link connecting the host device to a next-hop router). Hence, the host device selects a default router based on the a matching routing table entry matching the destination address prefix.
The Internet Draft by Draves et al., however, does not address ingress filtering nor the problems associated with redundancy of a multi-homed site, hence, the multi-homed host device may continue to send packets using a source address derived from an address prefix that has been assigned by the failed ISP: any rerouting within the multi-homed site will result in ingress filtering by the alternate exit router. Further, the Internet Draft by Draves et al. assumes there is more than one default gateway router available to the host device, and is inapplicable if the client device is in communication with only one default gateway router.